Machine-readable medium for storing a stream data processing program and computer system

ABSTRACT

In a stream data processing method in which part of stream data is defined as a processing target and the time control information which indicates the advance of the time is inserted into the stream data, time information of the received stream data is stored in a next ignition time holding area as an ignition time. A processing module for generating the time control information at a time different from the time of reception of the stream data is extracted out of a query that indicates how the stream data is to be processed. Based on the extracted processing module and the time information indicating the time of the reception of the stream data, the ignition time is calculated and stored in the next ignition time holding area. The time generation module inserts the time control information at the ignition time held in the next ignition time holding area.

CLAIM OF PRIORITY

The present application claims priority from Japanese patent applicationJP2008-276685 filed on Oct. 28, 2008, the content of which is herebyincorporated by reference into this application.

BACKGROUND OF THE INVENTION

This invention relates to a method of, in a stream data processingsystem, generating time control information inside the system andbetween the systems.

There has been an increasing demand for a data processing system whichcarries out real-time processing for data continuously arriving at adatabase management system (hereafter, referred to as “DBMS”), whichcarries out processes for data stored in the storage system.

Data which continuously arrives is defined as stream data, and there hasbeen proposed a stream data processing system as a data processingsystem suitable for the real-time processing for the stream data. Forexample, R. Motwani, J. Widom, A. Arasu, B. Babcock, S. Babu, M. Datar,G. Manku, C. Olston, J. Rosenstein, and R. Varma: “Query Processing,Approximation, and Resource Management in a Data Stream ManagementSystem”, In Proc. of the 2003 Conf. on Innovative Data Systems Research(CIDR), (online), January 2003, (retrieved on Oct. 15, 2008), disclosesa stream data processing system “STREAM”.

In the stream data processing system, first, queries are registered tothe system, and the queries are executed continuously each time dataarrives, which is different from the conventional DBMS. Theabove-mentioned STREAM employs an idea referred to as sliding window,which partially cuts stream data for efficiently processing the streamdata to thereby impart lifetime to the data. As a preferred example of aquery description language including a sliding window specification,there is a continuous query language (CQL) disclosed in R. Motwani, J.Widom, A. Arasu, B. Babcock, S. Babu, M. Datar, G. Manku, C. Olston, J.Rosenstein, and R. Varma: “Query Processing, Approximation, and ResourceManagement in a Data Stream Management System”, In Proc. of the 2003Conf. on Innovative Data Systems Research (CIDR), (online), January2003, (retrieved on Oct. 15, 2008). The CQL includes an extension forspecifying the sliding window by using parentheses following a streamname in a FROM clause of a structured query language (SQL), which iswidely used for the DBMS.

As for SQL, there is known one disclosed in C. J. Date, Hugh Darwen: “AGuide to SQL Standard (4th Edition)”, the United States, Addison-WesleyProfessional, Nov. 8, 1996, ISBN: 021964260. There are two types oftypical methods for specifying the sliding window: (1) a method ofspecifying the number of data rows to be cut, and (2) a method ofspecifying a time interval containing data rows to be cut. For example,“Rows 50 Preceding” described in a second paragraph of R. Motwani, J.Widom, A. Arasu, B. Babcock, S. Babu, M. Datar, G. Manku, C. Olston, J.Rosenstein, and R. Varma: “Query Processing, Approximation, and ResourceManagement in a Data Stream Management System”, In Proc. of the 2003Conf. on Innovative Data Systems Research (CIDR), (online), January2003, (retrieved on Oct. 15, 2008), is a preferred example of the item(1), in which data corresponding to 50 rows is cut to be processed, and“Range 15 Minutes Preceding” is a preferred example of the item (2), inwhich data for 15 minutes is cut to be processed. In the case of theitem (1), the data lifetime is defined to be until 50 pieces of dataarrive. In the case of the item (2), the data lifetime is defined to be15 minutes. The stream data cut by the sliding window is held on amemory, and is used for the query processing.

In the stream data processing, event extraction through an analysis inwhich a plurality of data sources are combined, the extraction of eventsthat have occurred within a given period of time, or other similarprocessing requires a heartbeat tuple (hereinafter abbreviated as HBT)to be generated and processed regularly within a data processing system.HBT is for advancing time during a period in which no data is generated.Each HBT has an HBT flag which indicates that it is an HBT, and timeinformation which indicates the time of generation of the HBT.

To give an example, in join operation where data sources of two or moreinputs are joined, the data sources of two or more inputs are obtainedin chronological order. In the case where the first input includes aninput from the data sources and the second input does not include aninput from the data sources, data having an earlier time than that ofthe data sources of the first input may be input to the second input.Because of this fear, the first input may not be processed, resulting ina wait. In such a case, the wait is solved if an HBT having timeinformation that is newer than that of the data sources of the firstinput is input to the data sources of the second input, thereby enablingthe system to process the first input.

One of the known methods is disclosed in Yijian Bai, Hetal Thakkar,Haixun Wang, Carlo Zaniolo: “Optimizing Timestamp Management in DataStream Management Systems”, IEEE 23rd International Conference on DataEngineering 2007, ICDE 2007, 15-20, April 2007, pp. 1334-1338, whereeach query maintains two states: an yield state (which means that thereis data in an output queue) and a more state (which means that there isdata in an input queue) to help determine an operator to be executednext. The method disclosed in Yijian Bai, Hetal Thakkar, Haixun Wang,Carlo Zaniolo: “Optimizing Timestamp Management in Data StreamManagement Systems”, IEEE 23rd International Conference on DataEngineering 2007, ICDE 2007, 15-20, April 2007, pp. 1334-1338 executesan execution tree starting from its input side and going as far alongthe execution tree as possible, and then tracks the execution tree backto an operator that may be executed next. When the execution tree istracked back to the input of stream data, Enabling Time-Stamps (ETSs,corresponding to HBTs) are propagated.

Another known method is disclosed in US 2008/0072221, where one logicaltime period is assigned to a plurality of physical time periods indispersed input sources, and event streams are rearranged within abuffer according to their “output bookmark” values.

SUMMARY OF THE INVENTION

Take a system that sells and buys stocks as an example. To the system,how fast the system may respond to a change in stock price is one of themost important matters. Storing stock data in a storage systemtemporarily and then conducting a search concerning the stored data asin conventional DBMSs takes too long for the speed of change in stockprice, possibly causing the system to miss a business chance. U.S. Pat.No. 5,495,600, for example, discloses a mechanism that executes a storedquery cyclically, but it is difficult to apply the mechanism toprocessing of real-time data such as stock prices, in which executing aquery the instant data is input is important.

In C. J. Date, Hugh Darwen: “A Guide to SQL Standard (4th Edition)”, theUnited States, Addison-Wesley Professional, Nov. 8, 1996, ISBN:021964260 where HBTs are generated and processed regularly within thedata processing system, processing timing is bound by the HBTs, with theresult that the HBT transmission interval appears as an average latencyfrom data generation to event extraction. Reducing the latency requiresan increased HBT generation rate, which causes a rise in CPU load,lowering in throughput and, ultimately, an overhead.

Further, in the case where a plurality of computers are involved andtime information in a first computer is used by a second computer forstream data processing, the need to transmit the time information in thefirst computer to the second computer creates a problem similar to theone described above.

In Yijian Bai, Hetal Thakkar, Haixun Wang, Carlo Zaniolo: “OptimizingTimestamp Management in Data Stream Management Systems”, IEEE 23rdInternational Conference on Data Engineering 2007, ICDE 2007, 15-20,April 2007, pp. 1334-1338, too, there are other cases than data inputwhere HBTs are generated, such as a range window operator that generatesa minus tuple (Negative Tuple Approach) or an RStream operator, whichmay not be dealt with by the method disclosed in Yijian Bai, HetalThakkar, Haixun Wang, Carlo Zaniolo: “Optimizing Timestamp Management inData Stream Management Systems”, IEEE 23rd International Conference onData Engineering 2007, ICDE 2007, 15-20, April 2007, pp. 1334-1338.There may arise another problem that a long execution tree with mayqueries registered needs to be tracked back many times.

In US 2008/0072221, HBTs are generated regularly, leaving unsolved theproblem of a rise in CPU load, lowering in throughput and, ultimately,an overhead as a result of increasing the HBT generation rate in anattempt to reduce the latency.

Stream data processing systems are thus expected to be applicable tofields where real-time processing is necessary, as typified by financialapplications, traffic information systems, distribution systems,traceability systems, sensor monitoring systems, and computer systemmanagement.

To summarize, stream data processing requires a data processing systemto internally perform regular generation and processing of time controlinformation for advancing time during a period in which no data isgenerated, in order to implement such processing as event extractionthrough an analysis in which a plurality of data sources are combined,or the extraction of events that have occurred within a given period oftime. However, with the processing timing determined by the time controlinformation, the transmission interval of the time control informationundesirably appears as an average latency (latency within a given periodof time) from data generation to event extraction. In other words, whenthere is executable processing during a period in which time controlinformation for advancing time is waited for, the processing start timein the data processing system is bound by the time control information,and the period in which the time control information is waited forappears as the latency. Reducing the latency requires an increasedgeneration rate of the time control information, which causes a rise inCPU load, lowering in throughput and, ultimately, an overhead.

Further, in the case where a plurality of computers are involved andtime information in a first computer is used by a second computer forstream data processing, the need to transmit the time information in thefirst computer to the second computer creates a problem similar to theone described above.

This invention has been made in view of the problems described above,and it is therefore an object of this invention to insert time controlinformation in stream data processing at the time when the time controlinformation is needed.

According to this invention, a machine-readable medium for storing astream data processing program for receiving, as primary information,stream data input to a computer comprising a processor and a storagesystem, creating secondary information by obtaining a given period ofthe received primary information as a processing target, and generatingtime control information indicating advance of time in addition to theprimary information, wherein the stream data processing program controlsthe computer to execute the procedures of: receiving the input streamdata as the primary information; calculating, by a time controlinformation generation module for generating, as the time controlinformation, time information at a time of reception of the primaryinformation, a time at which the time control information is generatedas a next ignition time, and storing the next ignition time in a nextignition time holding area, which is set in the storage system;generating the time control information when current time informationreaches the next ignition time held in the next ignition time holdingarea; and creating, upon reception of the generated time controlinformation, secondary information by obtaining the given period of thereceived primary information as the processing target.

By applying this invention, stream data processing that is small inlatency is accomplished while the amount of the time control informationis reduced.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a first embodiment of this invention, and is a blockdiagram showing a hardware configuration of a stream data processingsystem.

FIG. 2 is a block diagram illustrating a stream data processing systemto which a first embodiment of this invention is applied and a relevantsystem configuration.

FIG. 3A shows a first embodiment of this invention, and is a diagramschematically illustrating an example of a preferable data format of thestream data 21.

FIG. 3B shows a first embodiment of this invention, and is a diagramschematically illustrating an example of a preferable data format of thestream data 21.

FIG. 4 shows a first embodiment of this invention, and is an explanatorydiagram illustrating a description example of a preferable command forcausing the command input module 210 to register or set the stream data21 in the stream data processing sever 100.

FIG. 5 shows a first embodiment of this invention, and is an explanatorydiagram illustrating a description example of a preferable command forcausing the command input module 210 to register or set a queryregistration command in the stream data processing sever 100.

FIG. 6 shows a first embodiment of this invention, and is an explanatorydiagram illustrating an example of the query execution module 226.

FIG. 7 shows a first embodiment of this invention, and is an explanatorydiagram illustrating a configuration example of the query execution treeanalysis result management table 235.

FIG. 8 shows a first embodiment of this invention, and is a flow chartillustrating overall processing of the stream data processing sever 100.

FIG. 9 shows a first embodiment of this invention, and is a flow chartillustrating the ignition operator extraction and registrationprocessing in Step 802 of FIG. 8.

FIG. 10 shows a first embodiment of this invention, and is a flow chartillustrating the stream data input and registration processing in Step803 of FIG. 8.

FIG. 11 shows a first embodiment of this invention, and is a flow chartillustrating the next ignition time calculation processing in Step 804of FIG. 8.

FIG. 12 shows a first embodiment of this invention, and is a flow chartillustrating the HBT insertion (or generation) processing in Step 805 ofFIG. 8.

FIG. 13 shows a first embodiment of this invention, and is a sequencediagram exemplifying the next ignition time calculation processing andthe HBT generation processing.

FIG. 14 shows a first embodiment of this invention, and is a flow chartof storing a next ignition time in a next ignition time holding area.

FIG. 15 is a block diagram illustrating a configuration of the streamdata processing system to which the second embodiment of this inventionis applied and the system components related thereto.

FIG. 16 shows a second embodiment of this invention, and is a flow chartillustrating overall processing of the stream data processing sever 100and the application operation server 1500.

FIG. 17 shows a second embodiment of this invention, and is a flow chartillustrating the next ignition time calculation processing in Step 1603of FIG. 16.

FIG. 18 shows a second embodiment of this invention, and is a flow chartillustrating the processing that is executed by the STT generationmodule 1542 of the application operation server 1500 in Step 1605 ofFIG. 16.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Hereinafter, description is made of the first embodiment of thisinvention with reference to the drawings.

FIG. 1 illustrates a hardware configuration of a stream data processingsever 100. The stream data processing server 100 is executed on onecomputer, and includes a CPU 11 for performing an operation processing,a memory 12 for storing stream data 21 and a program for a stream dataprocessing, a disk drive 13 for storing data, and an interface 14 forcoupling the CPU 11 to the disk drive 13 and a network 112. It should benoted that the stream data processing sever 100 may be executed on aplurality of computers.

Sensor nodes such as a temperature sensor node 101 and a humidity sensornode 102 output data to be input as the stream data 21, and areconnected to a sensor base station 108 and a cradle 109 via a network105. In addition, an RFID tag 103 is connected to a radio frequencyidentification (RFID) reader 110 via a network 106. In addition, acellular phone 104 is connected to a cellular phone base station 111 viaa network 107. In addition, a stock information providing server 118which distributes stock price information may be input as the streamdata 21.

Connected to the network 112 are the sensor base station 108, the cradle109, the RFID reader 110, the cellular phone base station 111, the stockinformation providing server 118, a relay computer 113 for executing anapplication such as sensor middleware or an RFID middleware, a computer115 for inputting a command to the stream data processing sever 100, anda computer 117 that uses an output result 23 output from the stream dataprocessing sever 100.

The sensor base station 108 outputs measurement results (for example,temperature and humidity) from the temperature sensor node 101 and thehumidity sensor node 102, respectively, and the RFID reader 110 outputsinformation read from the RFID tag 103. The cellular phone base station111 outputs information received from the cellular phone 104. Thoseoutputs are input to the stream data processing sever 100 as the streamdata 21. The stream data 21 may be input to the stream data processingsever 100 directly from the sensor base station 108, the cradle 109, theRFID reader 110, the cellular phone base station 111, and the stockinformation providing server 118 via the network 112, or after havingbeen processed by the relay computer 113, the stream data 21 may beinput to the stream data processing sever 100.

In addition, a command 22 ordered by a user 114 or the command 22generated by the computer 115 is input to the stream data processingsever 100 via the network 112.

The output result 23 that is a result processed by the stream dataprocessing sever 100 is output to the computer 117 that is used by auser 116 via the network 112.

In this case, the stream data processing sever 100, the relay computer113, the computer 115, and the computer 117 are configured by anarbitrary computer system including a personal computer and aworkstation, and may be the same computer or different computers. Inaddition, the user 114 and the user 116 may be the same user ordifferent users. In addition, the networks 105, 106, 107, and 112 may beone of: a local area network (LAN) based on a connection by an Ethernet(registered trademark), an optical fiber, a fiber distributed datainterface (FDDI), a radio, or the like; a wide area network (WAN)including an Internet lower in speed than the LAN; a public telephonenetwork; and a similar technology which are invented in the future.

Here, a storage system 15 illustrated in FIG. 1 includes a predeterminedarea of the memory 12 and a predetermined area of the disk drive 13. Thestream data 21 is stored in the storage system 15 mainly within thememory 12, which allows a high speed search in response to a query. Thestream data processing sever 100 that manages the continuously-changingstream data 21 stores data to be a search target in the storage system15 within the memory 12, and data that is no longer needed for thepurpose of the high speed search may be stored in the storage system 15within the disk drive 13. For example, in a case where the stream data21 represents a measurement value (such as a temperature) output fromthe temperature sensor node 101, the measurement value to be monitoredaccording to an intention of the user 114 may be a today's value, andhence there arises no problem even if a value obtained on a previous daymay not be searched for at high speed. Therefore, the stream dataprocessing sever 100 may store the today's measurement value within thememory 12, the measurement value obtained on a previous day within thedisk drive 13 as an archive. Here, the storage system 15 may be anyrecording medium such as a memory, a disk, a tape, and a flash memory.In addition, the storage system 15 may have a hierarchical structureincluding a plurality of recording media. In addition, the storagesystem 15 may be realized by a similar technology which is invented inthe future.

In FIG. 1, the stream data processing sever 100 is a computer (orserver) that executes the stream data processing, in which informationtransmitted in real time from the sensor base station 108, or from theRFID reader 110, or from an application that is run on the relaycomputer 113, is input to the stream data processing sever 100 via theI/F 14 as the stream data 21, the input stream data 21 is converted intoa significant information according to the command 22, which is inputfrom the user 114 or from an application run on the computer 115, so asto be created as the output result 23, and the output result 23 isprovided to the user 116 or to an application run on the computer 117.The stream data 21 includes a plurality of stream data 21 ₁, 21 ₂, . . ., 21 _(n).

The computer 115 is connected to the stream data processing sever 100via the network 112. The application run on the computer 115 and theapplication run on the computer 117 may be the same application ordifferent applications.

The stream data 21 discussed in this embodiment differs from a streamused in the distribution of video and sound, in that each piece ofstream data corresponds to significant information. The stream data 21which the stream data processing sever 100 receives from the sensor basestation 108, or from the RFID reader 110, or from an application run onthe relay computer 113 is continuous or intermittent, and each piece ofstream data contains different product information or a differentelement.

FIG. 2 is a block diagram illustrating a stream data processing systemto which an embodiment of this invention is applied and a relevantsystem configuration.

The stream data processing sever 100 includes the CPU 11, the memory 12,the disk 13, and the I/F 14. The memory 12 contains an operating system(OS) 200, a command input module 210, and a stream data processingmodule 220. The stream data processing module 220 and the command inputmodule 210 are constituted of programs and stored in the disk 13 orother storage media. When stream data processing is performed, the CPU11 loads the stream data processing module 220 and the command inputmodule 210 onto the memory 12 to execute the modules 210 and 220.

The command input module 210 receives a command input by the user 114 orby the application running on the computer 115. Subsequently, the streamdata processing module 220 converts, based on the query which has beenreceived by the command input module 210 which represents a content of aprocessing for converting information on the stream data intosignificant information, the information on the stream data 21 intosignificant information, and outputs the significant data.

Referring to FIG. 2, description is made of an outline of thisinvention. In the stream data processing sever 100, based on the queryinput by the user 114 or by the application running on the computer 115,the query execution module 230 reads the stream data 21, converts theinformation on the stream data 21 into significant information, and thenoutputs the output result 23. Here, the term “significant information”represents, for example, information obtained by converting themeasurement value output from the temperature sensor node 101illustrated in FIG. 1, which would not be understood by the user 114 or116 if remaining being a data series of measurement value, into anaverage value of temperatures obtained within a predetermined time.

Hereinafter, detailed description is made of the configuration of thestream data processing sever 100.

The command input module 210 includes an interface (hereinafter,referred to as I/F) for receiving the command 22 ordered by the user 114through the computer 115, or the command 22 input by an applicationrunning on the computer 115. In the case where the command 22 is acommand relevant to stream data, the stream data processing module 220receives the command input from the command input module 210 as a streamdata registration/change command for registering or changing the streamdata, and updates a table (not shown) that is used to manage streamdata.

In the case where the command 22 is a command relevant to a query, thestream data processing module 220 receives the command input from thecommand input module 210 as a query registration/change command forregistering or changing the query, updates a table (not shown) the isused to manage queries, and creates or changes an execution tree thatindicates the specifics of stream data processing to be executed inresponse to the query command. The stream data processing module 220transmits the created execution tree to a query execution module 226 tobe stored.

The stream data processing module 220 includes a stream data receivingmodule 221, a query execution tree scheduler 222, a next ignition timecalculating module 223, a heartbeat tuple (HBT) generation module 224, aquery execution tree analyzing module 225, the query execution module226, an input stream data holding buffer 231, a system timestamp holdingarea 232, an HBT generation-use data processing time holding area 233, anext ignition time holding area 234, a query execution tree analysisresult management table 235, an operator joining queue 236, and anoutput result holding buffer 237.

The input stream data holding buffer 231 is a buffer that holds thestream data 21 input to the stream data processing sever 100 via the I/F14. The system timestamp holding area 232 is a area for holding thecurrent time of the system. The current time of the system in thisembodiment is absolute time information (e.g., current time managed bythe OS 200) that the stream data processing sever 100 has.Alternatively, the current time of the system may be a value updatedwith time information that is input from the outside of the stream dataprocessing sever 100. For example, time information attached to thestream data 21 may be used to update the current time of the system whenthe stream data 21 containing the latest time information is input.

The stream data receiving module 221 obtains the stream data 21 of theinput stream data holding buffer 231, attaches the current time of thesystem that has been held in the system timestamp holding area 232 tothe obtained stream data 21, and outputs the resultant data to the HBTgeneration module 224.

The query execution module 226 indicates how the stream data 21 is to beprocessed, and contains processing modules such as window operation,filter operation, projection operation, join operation, and aggregationoperation which are arranged in a tree structure. In the followingdescription, these processing modules are called operators, and the treestructure is referred to as execution tree. An execution tree in thequery execution module 226 is created when a command relevant to a queryis input to the command input module 210. The query execution module 226receives data output from the HBT generation module 224, and stores aresult of processing executed by the operators that constitute theexecution tree, in the output result holding buffer 237. Midway resultsof processing executed respectively by the operators are stored in theoperator joining queue 236. The execution tree of the query executionmodule 226 is similar to the one disclosed in JP 2008-123426 A, whichhas been filed by the applicant of this invention, and is not describedin detail here.

The query execution tree scheduler 222 controls the HBT generationmodule 224 and the order of executing operators in the query executionmodule 226.

The operator joining queue 236 is a buffer that holds midway results ofprocessing executed respectively by the operators. The output resultholding buffer 237 is a buffer that stores a processing result outputfrom the query execution module 226. The output result stored in theoutput result holding buffer 237 is output to the computer 117, which isillustrated in FIG. 1, via the I/F 14.

The query execution tree analyzing module 225 analyzes an execution treein the query execution module 226 to extract an operator that generatesthe HBT at a time different from the time of reception of the streamdata 21, and stores the extracted operator and query settingsinformation in the query execution tree analysis result management table235. The query execution tree analysis result management table 235 is atable that stores an analysis result obtained by the query executiontree analyzing module 225.

The next ignition time calculating module 223 refers to the queryexecution tree analysis result management table 235 to calculate a nextignition time, based on time information of input stream data and thequery settings information which is stored in the query execution treeanalysis result management table 235, and stores the calculated nextignition time in the next ignition time holding area 234.

A next ignition time is a time at which processing is started in thequery execution module 226 on other occasions than the arrival of thestream data 21.

The next ignition time calculating module 223 is called up when anoperator extracted by the query execution tree analyzing module 225 isexecuted in the query execution module 226. The next ignition timeholding area 234 is a area for holding a next ignition time calculatedby the next ignition time calculating module 223.

The HBT generation module 224 obtains the stream data 21 from the streamdata receiving module 221, stores the time of reception of the streamdata 21 in the HBT generation-use data processing time holding area 233,and outputs the stream data 21 to the query execution module 226. TheHBT generation-use data processing time holding area 233 is a area forholding a final time at which the HBT generation module 224 finishesprocessing the stream data 21.

The HBT generation module 224 also refers to the system timestampholding area 232, the HBT generation-use data processing time holdingarea 233, and the next ignition time holding area 234. Using the currenttime of the system which is held in the system timestamp holding area232, the next ignition time which is held in the next ignition timeholding area 234, and the final processing time of the HBT generationmodule 224 which is held in the HBT generation-use data processing timeholding area 233, the HBT generation module 224 outputs an HBT to thequery execution module 226 at the ignition time. Details of this processare described later.

The stream data 21, the output result 23, HBTs, which are describedlater, and temporarily stored data, which is kept by an operator forprocessing, may have any data format including the tuple format (recordformat), the XML format, and the CSV file format. The tuple format isused in the example given below.

The stream data 21, the output result 23, HBTs, which are describedlater, and temporarily stored data, which is kept by an operator forprocessing, do not need to be actual data, and may include partially orentirely a pointer that points to the actual data.

FIGS. 3A and 3B are diagrams each schematically illustrating an exampleof a preferable data format of the stream data 21. FIG. 3A illustratestemperature stream data (S1) 21 ₁, which is output from the temperaturesensor node 101. FIG. 3B illustrates humidity stream data (S2) 21 ₂,which is output from the humidity sensor node 101.

The temperature stream data (S1) 21 ₁ is of record format, and atemperature sensor ID column 302, a device ID column 303, a temperaturecolumn 304, and a system timestamp column 305, which constitute arecord, correspond to segments. A combination of the temperature sensorID column 302, the device ID column 303, the temperature column 304, andthe system timestamp column 305 is referred to as tuple 301.

As the value of the system timestamp column 305, the stream dataprocessing sever 100 attaches time information indicating a time atwhich the temperature stream data (S1) 21 ₁ arrives at the stream dataprocessing sever 100 when the data is input thereto.

Alternatively, time information that is attached to the stream databefore the stream data is input to the stream data processing sever 100may be used as the value of the system timestamp column 305. Forexample, the value of the system timestamp column 305 may be timeinformation attached by the temperature sensor 101, or the sensor basestation 108, or sensor net middleware or other applications running onthe relay computer 113, before the temperature stream data (S1) 21 ₁ isinput to the stream data processing sever 100.

The humidity stream data (S2) 21 ₂ of FIG. 3B is of another recordformat, and a humidity sensor ID column 312, a device ID column 313, ahumidity column 314, and a system timestamp column 315, which constitutea record, correspond to a segment. A combination of the humidity sensorID column 312, the device ID column 313, the humidity column 314, andthe system timestamp column 315 is referred to as tuple 311.

As the value of the system timestamp column 315, the stream dataprocessing sever 100 attaches time information indicating a time atwhich the humidity stream data (S2) 21 ₂ is input to and arrives at thestream data processing sever 100 when the data is input thereto.

Alternatively, time information that is attached to the stream databefore the stream data is input to the stream data processing sever 100may be used as the value of the system timestamp column 315. Forexample, the value of the system timestamp column 315 may be timeinformation attached by the temperature sensor 101, or the sensor basestation 108, or sensor net middleware or other applications running onthe relay computer 113, before the humidity stream data (S2) 21 ₂ isinput to the stream data processing sever 100.

FIG. 4 is an explanatory diagram illustrating a description example of apreferable command for causing the command input module 210 to registeror set the stream data 21 in the stream data processing sever 100.

A stream registration command 401 is instructed by the user 114 from thecomputer 115 or registered through the command input module 210 from theapplication 116 running on the client computer 115. The streamregistration command 401 represents a command for registering streamdata that is the temperature stream data (S1) 21 ₁ constituted of atemperature sensor ID holding an integer type (int type), a device IDholding an integer type (int type), and a temperature holding a floatingpoint type (double type), which correspond to the temperature sensor IDcolumn 302, the device ID column 303, and the temperature column 304,respectively, illustrated in FIGS. 3A and 3B.

In addition, a stream registration command 402 represents a command forregistering stream data that is the humidity stream data (S2) 21 ₂constituted of a temperature sensor ID holding an integer type (inttype), a device ID holding an integer type (int type), and a temperatureholding a floating point type (double type), which correspond to thetemperature sensor ID column 312, the device ID column 313, and thetemperature column 314, respectively, illustrated in FIGS. 3A and 3B.

The command input module 210 may transform commands forregistering/setting the stream data 21 in the stream data processingsever 100 into a table format to keep a table where the commands areheld in a storage medium.

In this embodiment, the system timestamp column 305 and the systemtimestamp column 315 are automatically included, but the streamregistration command 411 may be specified explicitly as “register streamtemperature stream (timestamp, temperature sensor ID int, device ID int,temperature double);”.

In addition, this embodiment has been described by taking an examplewhere a command is registered in a command line interface (CLI) format,but there is no limitation thereto. For example, a graphical userinterface (GUI), an input in a table format, an input through a settingfile, and an input through an XML file may be used to perform an inputhaving the same meaning as described above. The same holds true of thefollowing commands.

In addition, according to this embodiment, the timestamp has a formatincluding a time and a minute such as “9:00”, the timestamp may haveother format such as one typified by a format additionally including adate and a second such as “2007/9/21 9:00:00 JST”. The same holds truein the following drawings.

FIG. 5 is an explanatory diagram illustrating a description example of apreferable command for causing the command input module 210 to registeror set a query registration command in the stream data processing sever100.

A query registration command 501 is registered by the user 114 or theapplication 116 running on the client computer 115, through the commandinput module 210.

The query registration command 501 is for registering a query thatindicates the following processing, in which: among the past two minutes([Range 2 minutes]) of the temperature stream data (S1) 21 ₁ and onelatest piece ([Partition by S1 temperature sensor ID rows 1]) of thehumidity stream data (S2) 21 ₂ of each humidity sensor ID, a tuple ofthe temperature stream data (S1) 21 ₁ and a tuple of the humidity streamdata (S2) 21 ₂ are joined (WHERE S1. temperature sensor ID=S2. humiditysensor ID) only when a condition that the temperature of the temperaturestream data (S1) 21 ₁ is 20° or higher (S1. temperature>=20) and acondition that the humidity of the humidity stream data (S2) 21 ₂ is 60%or higher (S2. temperature>=60) are satisfied, and the temperaturesensor ID of the temperature stream data (S1) 21 ₁ matches the humiditysensor ID of the humidity stream data (S2) 21 ₂, and an average value ofthe temperature (Avg(S1. temperature)) and an average value of thehumidity (Avg(humidity)) are calculated on a device ID basis (GROUP BYS1. device ID), and only increments of tuples each constituted of atemperature sensor ID, the average value of the temperature, and theaverage value of the humidity are turned into stream data (ISTREAM),which is output with a delay of one minute (<1 minute>).

In a query registration command 502, “[Range 2 minutes]” of the queryregistration command 501 is replaced with “[Jumping 10 minutes]”, whichindicates that processing target is switched at ten-minute intervals.For instance, while data input at 9:01 is a processing target until 9:03and data input at 9:04 is a processing target until 9:06 in the case oftime window (Range 2 minutes), data input at 9:01 and data input at 9:04are both processing targets in a 9:00-9:10 period (from 9:00 up to andnot including 9:10) and the processing target is switched upon 9:10 todata input in a 9:10-9:20 period in the case of jumping window (Jumping10 minutes). Further, “ISTREAM ( )<1 minute>” of the query registrationcommand 501 is replaced with “RSTREAM [5 minutes]” in the queryregistration command 502, and hence a tuple group of the average valuesis output for every five minutes.

The command input module 210 may transform commands forregistering/setting a query registration command in the stream dataprocessing sever 100 into a table format to keep a table where thecommands are held in a storage medium.

FIG. 6 is an explanatory diagram illustrating an example of the queryexecution module 226.

A query execution module 226 ₁ represents the query execution module 226that is created when the query registration commands 501 and 502 of FIG.5 is executed. The query execution module 226 includes operators forperforming processing and an operator joining queue 236 which links oneoperator with another. In this explanatory diagram, the left end is theinput side and the right end is the output side. The stream data 21 isinput as input data. Each piece of data in a data row input as thestream data 21 is referred to as tuple 601. The tuple 601 is processedby the operators and stored in the operator joining queue 236. Afterprocessed in the stream data receiving module 221 and the HBT generationmodule 224, which are illustrated in FIG. 2, the tuple 601 is input tothe query execution module 226 via the operator joining queue 236. Aquery processing result of an execution tree 241 is output as the outputresult 23. The output result 23 may be re-input as different stream data21.

The operators vary in type depending on their processing contents.Window operators 611 and 612 illustrated in FIG. 6 cut out data rowsfrom the stream data 21 by specifying the number of data rows or a timeinterval for cutting out data rows, and perform a processing ofconverting the stream data into a tuple set. The tuple cut out are heldin the window operators 611 and 612. Filter operators 613 and 614perform a processing of determining whether or not the tuples 301 and311 illustrated in FIGS. 3A and 3B, respectively, are output, based onpredetermined conditions. A join operator 615 performs a processing ofjoining two or more stream data 21 under a given condition. Anaggregation operator 616 performs an aggregation processing representedby derivation of a sum, an average, a maximum, a minimum, or the like. Arelation-to-stream operator 617 performs a processing of converting thetuple set as the output result 23 into the stream data 21. In additionto the operators illustrated in FIG. 6, there are a projection operatorfor performing a processing of outputting only a portion of the columnsof the delay tuple 203 and other such operators.

An execution tree 241 ₁ represents the execution tree 241 that iscreated when the query registration commands 501 and 502 illustrated inFIG. 5 are executed. The temperature stream data 21 ₁ and the humiditystream data 21 ₂ are input data of the execution tree 241 ₁. The windowoperator 611 keeps past two minutes of ([Range 2 minutes]) thetemperature stream data 21 ₁, and outputs a tuple that has newly enteredthe window and a tuple that has left the window, to the filter operator613.

The window operator 612 holds the tuple of the humidity stream data 21 ₂within the range of past two minutes ([Range 2 minutes]) in the windowoperator 612, and outputs to the filter operator 614 a tuple that hasnewly entered a window and a tuple that has left the window.

From among tuples output from the window operator 611, the filteroperator 613 outputs a tuple that satisfies the condition that thetemperature is 20° C. or higher (S1.humidity>=20), to the join operator615.

From among tuples output from the window operator 612, the filteroperator 614 outputs a tuple that satisfies the condition that thehumidity is 60% or higher (S2.humidity>=60), to the join operator 615.

If the temperature sensor ID of the tuple output from the filteroperator 613 matches the humidity sensor ID of the tuple output from thefilter operator 614 (WHERE S1.temperature sensor ID=S2.humidity sensorID), the join operator 615 joins the two tuples, and outputs thosetuples to the aggregation operator 616. It should be noted that in orderto select the tuples to be joined, the join operator 615 holds thetuples output from the filter operators 613 and 614 in the temporarystorage areas. It should be noted that the tuples held in the temporarystorage areas may be data entities or may be data containing pointersdirected to the window operators 611 and 612.

With respect to tuples output from the join operator 615, theaggregation operator 616 calculates the average value of the temperatureof the temperature stream data 21 ₁ (Avg(S1.temperature)) and theaverage value of the humidity (Avg(S2.humidity)) on a device ID basis(GROUP BY S1. device ID), and outputs the temperature sensor ID, theaverage value of the temperature, and the average value of the humidityto the relation-to-stream operator 617. It should be noted that theaggregation operator 616 holds tuples for calculating an aggregationvalue, in the temporary storage area.

From among tuples output from the aggregation operator 616, therelation-to-stream operator 617 converts a tuple that exhibits anincrease into a stream by 1 minute (ISTREAM <1 minute>), and outputs thestream as the output result 23 ₁.

An example of the operation of the execution tree 241 ₁ is as follows.

Consider a case where a tuple (temperature sensor ID, device ID,temperature)=(1001, 201, 23° C.) is input at 9:00 to the temperaturestream data 21 ₁. The stream data receiving module 221 attaches currentsystem timestamp information to the tuple as the value of the systemtimestamp column 305 illustrated in FIG. 3, and outputs a tuple 601 ₁(temperature sensor ID, device ID, temperature, system timestamp)=(1001,201, 23° C., 9:00).

An HBT generation module 224 ₁ outputs a heartbeat tuple (HBT) 604 ₁ foradvancing the time within the query execution module 226 during a periodin which no data is generated. The HBT 604 ₁ has an HBT flag whichindicates that it is an HBT, and a system timestamp. For example, theHBT 604 ₁ that is output at 9:03 is “(HBT, 9:03)”. An HBT updates anoperator processing time, which is managed by each operator, uponreception of the HBT by the operator, and is stored in the next operatorjoining queue 236. How an HBT is generated is described later.

When the window of data that the window operator 611 cuts out is thepast two minutes of data ([Range 2 minutes]), the processing targetperiod (lifetime) of the tuple 601 ₁ is from 9:00 to 9:02.

In order to designate the lifetime of the tuple 601 ₁, the windowoperator 611 outputs a plus tuple 602 ₁, which has a plus flagindicating the start of the lifetime of a tuple, at the beginning of thetuple's lifetime, and outputting a minus tuple 603 ₁, which has a minusflag indicating the end of the lifetime of a tuple, on the expiration ofthe tuple's lifetime. The plus tuple 602 ₁ and minus tuple 603 ₁ of thetuple “(1001, 201, 23° C., 9:00)” are “(+, 1001, 201, 23° C., 9:00)” and“(−, 1001, 201, 23° C., 9:00)”, respectively.

The window operator 611 outputs the tuple 602 ₁ upon reception of thetuple 601 ₁ and keeps the output tuple in a temporary storage area. Thewindow operator 611 subsequently receives the HBT 604 ₁ and stores anHBT 604 ₂ in the operator joining queue 236. Upon reception of the HBT,the operator processing time that is managed by the window operator 611is updated from “9:00” to “9:03”, thereby allowing the window operator611 to output the minus tuple 603 ₁. When the HBT 604 ₁ that is outputat 9:03 is used to output the minus tuple 603 ₁, a time period from 9:02to 9:03 appears as a latency of the query execution module 226 ₁. Thislatency corresponds to the one described above as a problem of the priorart. In order to reduce the latency in outputting the minus tuple 603 ₁,the window operator 611 needs to receive the HBT at 9:02.

The minus tuple 603 ₁ is also referred to as negative tuple. Thisembodiment may employ any other methods to designate the lifetime of atuple than the one described above, including embedding a lifetime endindicator in the tuple.

The HBT 604 ₁ is also necessary for an operator such as the joinoperator 615 which handles two or more inputs. For example, the joinoperator 615 obtains tuples from an operator joining queue 236 ₂ and anoperator joining queue 236 ₃ in chronological order by timestamp.

In the case where a plus tuple 602 ₂ “(+, 1001, 201, 21° C., 8:40)” isin the operator joining queue 236 ₂ and a plus tuple 602 ₃ “(+, 1001,201, 69%, 8:30)” is in the operator joining queue 236 ₃, the joinoperator 615 first obtains the plus tuple 602 ₃ from the operatorjoining queue 236 ₃. The join operator 615 next tries to obtain the plustuple 602 ₂ from the operator joining queue 236 ₂ but fails to obtainthe plus tuple 602 ₂ because of the possibility that data prior to 8:40is stored in the operator joining queue 236 ₃. An HBT 604 ₃ “(HBT,8:45)” stored in the operator joining queue 236 ₃ at this point allowsthe join operator 615 to obtain the plus tuple 602 ₂ and executeprocessing.

The aggregation operator 616 sometimes generates a tuple called ghost,which has the same timestamp as its lifetime start time and lifetime endtime and accordingly has no lifetime. For example, when the humiditycolumns of aggregation target tuples have values “64, 66, 68, 70, and72”, the average value of the humidity columns is “68”. The arrival of aminus tuple 603 ₂ “(−, 64, 8:20)” at a timestamp “8:20” changes theaverage value of the humidity to an average of “66, 68, 70, and 72”which is “69”, and causes a plus tuple that has an aggregation value“69” to be created. However, the arrival of a plus tuple 602 ₄ “(+, 74,8:20)” which has the same timestamp changes the average value of thehumidity to an average of “66, 68, 70, 72, and 74” which is “70”, and aminus tuple having an aggregation value “69” and a plus tuple having anaggregation value “70” are created as a result. This makes the plustuple having an aggregation value “69” a tuple that has no lifetime. Theaggregation operator 616 may exclude the ghost if a tuple that has asystem timestamp later than 8:20 arrives. For example, the arrival ofthe HBT 604 ₃ “HBT, 8:45” which has a system timestamp “8:25” settlesthe aggregation value of 8:40, and enables the aggregation operator 616to output the plus tuple having an aggregation value “70”.

This embodiment uses the aggregation operator 616 to exclude the ghostbut other operators may be used to exclude the ghost. For example, theghost may be excluded by the relation-to-stream operator 617. Everyaggregation operator 616 has the ghost excluding function in thisembodiment. The ghost excluding function may instead be turned on or offon an individual operator basis by an input that is in the command lineinterface (CLI) format, the graphic user interface (GUI) format, a tableformat, a setting file format, or an XML file format. Alternatively, anaverage having the ghost excluding function may be described in a querysuch as AVG_G.

The chronological order of plus tuples and HBTs in an execution tree ofthis embodiment is never reversed within an operator joining queue andbetween operators that have a parent-child relation in the graphstructure, and hence it is always true that a timestamp on the inputside is new whereas a timestamp on the output side is old.

FIG. 7 is an explanatory diagram illustrating a configuration example ofthe query execution tree analysis result management table 235.

In a target operator column 701, an operator extracted by the queryexecution tree analyzing module 225 of FIG. 2 is stored. Stored in asetting item column 702 is an item that is set to the operator extractedby the query execution tree analyzing module 225, such as the windowsize, the delay size, or the output interval. Stored in a last executiontime column 703 is a time at which the target operator has executedprocessing and output a result last time in the case where the targetoperator is a jumping window operator, or a relation-to-stream operator(RStream) that outputs at regular intervals.

For example, a row 704 of the query execution tree analysis resultmanagement table 235 is for an operator extracted as a result ofanalyzing an execution tree that is created from the query registrationcommand 501 of FIG. 5. Details of how the operator is extracted aredescribed later.

The row 704 illustrates that the target operator column 701, the settingitem column 702, and the last execution time column 703 have a value“window operator 611 (Range Window)”, a value “sliding window size=2minutes”, and “−”, respectively.

The table for managing query execution tree analysis results may haveany other formats than the table format illustrated in FIG. 7, and maybe in a setting file format or an XML file format. The same applies toall tables described below.

FIG. 8 is a flow chart illustrating overall processing of the streamdata processing sever 100. This processing is started when, for example,an administrator of the stream data processing sever 100 activates thestream data processing module 220.

First, the query execution tree analyzing module 225 of FIG. 2 extractsan ignition operator from a query execution tree of a registered query,and registers the extracted query in the query execution tree analysisresult management table 235 (802). Details of Step 802 are describedlater with reference to FIG. 9. An ignition operator refers to anoperator that needs to start processing without waiting for the arrivalof the stream data 21. An operator that has time constraints related toprocessing, such as an operator that outputs a processing result atregular time intervals, qualifies as the ignition operator.

Next, the HBT generation module 224 stores time information indicatingthe time of reception of the stream data 21 in the HBT generation-usedata processing time holding area 233 of another HBT generation module224 (803). Details of Step 803 are described later with reference toFIG. 10.

The next ignition time calculating module 223 then calculates a nextignition time and stores the calculated next ignition time in the nextignition time holding area 234 (804). Details of Step 804 are describedlater with reference to FIG. 11.

At the next ignition time held in the next ignition time holding area234, the HBT generation module 224 inserts (generates) an HBT (805).Details of Step 805 are described later with reference to FIG. 12.

Whether or not the command input module 210 has received a system endcommand is determined next (806). When the answer to Step 806 is NO, theprocessing returns to Step 802. When the answer to Step 806 is YES, theprocessing of the stream data processing sever 100 is ended (807).

FIG. 9 is a flow chart illustrating the ignition operator extraction andregistration processing in Step 802 of FIG. 8.

The query execution tree analyzing module 225 repeats Step 903 to Step912 for every operator in the query execution module 226 of FIG. 2(902).

First, whether or not the target operator is a sliding window operator(Range Window) that indicates a time period is determined (903). Whenthe answer to Step 903 is YES, this target operator and the slidingwindow size of the target operator are registered in the query executiontree graph analysis result management table 235 (904).

When Step 904 is finished, or when the answer to Step 903 is NO, whetheror not the target operator is a jumping window operator (Jumping Window)that indicates a time period is determined (905). When the answer toStep 905 is YES, this target operator and the jumping window size of thetarget operator are registered in the query execution tree graphanalysis result management table 235 (906).

When Step 906 is finished, or when the answer to Step 905 is NO, whetheror not the target operator is a relation-to-stream operator thatindicates a time period and that causes a delay (IStream, DStream,IDStream) is determined (907). When the answer to Step 907 is YES, thistarget operator and the delay size of the target operator are registeredin the query execution tree graph analysis result management table 235(908).

When Step 908 is finished, or when the answer to Step 907 is NO, whetheror not the target operator is a relation-to-stream operator thatindicates a time period and that outputs at regular intervals (RStream)is determined (909). When the answer to Step 909 is YES, this targetoperator and the output interval of the target operator are registeredin the query execution tree graph analysis result management table 235(910).

When Step 910 is finished, or when the answer to Step 909 is NO, whetheror not the target operator is an operator that has a ghost excludingfunction (Sum, Count, Average, MM, Max, Median, Variable, StandardDeviation, Limit) is determined (911). When the answer to Step 911 isYES, this target operator and a minimum time unit (e.g., 1 millisecond,1 nanosecond, or a serially numbered time period under 1 millisecond)(912).

When Step 912 is finished, or when the answer to Step 911 is NO, theprocessing returns to Step 902 to repeat Steps 903 to 912 again. Whenevery operator has been processed, Step 802 is finished (913).

Given below is an example in which the query execution tree analysisresult management table 235 of FIG. 7 is created through the processingof FIG. 9 with the use of the query registration commands 501 and 502 ofFIG. 5 and the query execution module 226 ₁ of FIG. 6.

The query execution module 226 ₁ of FIG. 6 is created upon registrationof the query registration command 501 of FIG. 5. The stream dataprocessing module 220 executes the flow chart of FIG. 9 for the queryexecution tree analysis result management table 235 of FIG. 7.

First, YES is given as the answer to Step 903 because the windowoperator 611 is a sliding window operator (Range window, [Range 2minutes]) that indicates a time period, and “window operator 611” and“sliding window size=2 minutes” are registered in the row 704 of thequery execution tree analysis result management table 235.

Next, NO is given as the answer in all of Steps 903, 905, 907, 909, and911 because the window operator 612 is a group-based row window operator(Partitioned window, [Partition by S1 humidity sensor ID rows 1]).Similarly, the answer is NO in all of Steps 903, 905, 907, 909, and 911for the filter operator 613, the filter operator 614, and the joinoperator 615.

For the aggregation operator 616 which is an operator having a ghostexcluding function (Avg(S1. temperature), Avg(S2. humidity)), the answerto Step 911 is YES, and “aggregation operator 616” and “minimum timeunit” are registered in a row 705 of the query execution tree analysisresult management table 235.

For the relation-to-stream operator 617 which is a relation-to-streamoperator that causes a delay (ISTREAM ( ) <1 minute>), the answer toStep 907 is YES, and “relation-to-stream operator 617” and “delay size=1minute” are registered in a row 706 of the query execution tree analysisresult management table 235.

When the query registration command 502 of FIG. 5 is registered, thequery execution module 226 that is similar to the query execution module226 ₁ of FIG. 6 is created, and the flow chart of FIG. 9 is executed.

The description “[Jumping 10 minutes]” in the query registration command502 creates a jumping window operator (Jumping window) that indicates atime period. Accordingly, YES is given as the answer to Step 905 and“window operator xxx” and “jumping size=10 minutes” are registered in arow 707 of the query execution tree analysis result management table235.

The description “RSTREAM [5 minutes]” in the query registration command502 creates a relation-to-stream operator (RStream) that outputs atregular intervals. Accordingly, YES is given as the answer to Step 909and “window operator yyy” and “output interval=5 minutes” are registeredin a row 708 of the query execution tree analysis result managementtable 235.

While every aggregation operator has the ghost excluding function inthis embodiment, the ghost excluding function may instead be turned onor off on an individual operator basis by an input that is in thecommand line interface (CLI) format, the graphic user interface (GUI)format, a table format, a setting file format, or an XML file format.Alternatively, an average having the ghost excluding function may bedescribed in a query such as AVG_G.

Through the processing described above, ignition operators that havetime constraints in starting processing are registered in the queryexecution tree graph analysis result management table 235.

FIG. 10 is a flow chart illustrating the stream data input andregistration processing in Step 803 of FIG. 8.

First, the HBT generation module 224 determines whether or not thestream data receiving module 221 illustrated in FIG. 2 has received thestream data 21 (1002). When the answer to Step 1002 is YES, the HBTgeneration module 224 that has received the stream data 21 registersinput time information indicating the time of reception of the streamdata 21 in the next ignition time holding area 234 of another HBTgeneration module 224 (1003). The HBT generation module 224 updates afinal data input time in the HBT generation-use data processing timeholding area 233 with the value of the input time information of thereceived stream data 21 (1004).

When Step 1004 is finished, or when the answer to Step 1002 is NO, Step803 is ended (1005).

FIG. 11 is a flow chart illustrating the next ignition time calculationprocessing in Step 804 of FIG. 8.

First, the next ignition time calculating module 223 determines whetheror not the target operator is a sliding window operator (Range Window)that indicates a time period (1102). When the answer to Step 1102 isYES, the sum of the value of time information that is attached to atuple input to the target operator in the query execution module 226 andthe value of the sliding window size of the target operator that isregistered in the query execution tree graph analysis result managementtable 235 is registered in the next ignition time holding area 234(1103).

When Step 1103 is finished, or when the answer to Step 1102 is NO, thenext ignition time calculating module 223 determines whether or not thetarget operator is a jumping window operator (Jumping Window) thatindicates a time period (1104). When the answer to Step 1104 is YES, thesum of the value of time information indicating a time at which thetarget operator in the query execution module 226 has executedprocessing last time and the value of the jumping window size of thetarget operator that is registered in the query execution tree graphanalysis result management table 235 is registered in the next ignitiontime holding area 234 (1105).

When Step 1105 is finished, or when the answer to Step 1104 is NO, thenext ignition time calculating module 223 determines whether or not thetarget operator is a relation-to-stream operator (IStream, DStream,IDStream) that indicates a time period and that causes a delay (1106).When the answer to Step 1106 is YES, the sum of the value of timeinformation that is attached to a tuple input to the target operator inthe query execution module 226 and the value of the delay size of thetarget operator that is registered in the query execution tree graphanalysis result management table 235 is registered in the next ignitiontime holding area 234 (1107).

When Step 1107 is finished, or when the answer to Step 1106 is NO, thenext ignition time calculating module 223 determines whether or not thetarget operator is a relation-to-stream operator (RStream) thatindicates a time period and that outputs at regular intervals (1108).When the answer to Step 1108 is YES, the sum of the value of timeinformation indicating a time at which the target operator in the queryexecution module 226 has executed processing last time and the value ofthe output interval of the target operator that is registered in thequery execution tree graph analysis result management table 235 isregistered in the next ignition time holding area 234 (1109).

When Step 1109 is finished, or when the answer to Step 1108 is NO, thenext ignition time calculating module 223 determines whether or not thetarget operator is an operator (Sum, Count, Average, Min, Max, Median,Variable, Standard Deviation, Limit) that has a function of excludingghosts (1110). When the answer to Step 1110 is YES, the sum of the valueof time information that is attached to a tuple input to the targetoperator in the query execution module 226 and the value of the minimumtime unit of the target operator that is registered in the queryexecution tree graph analysis result management table 235 is registeredin the next ignition time holding area 234 (1111).

When Step 1111 is finished, or when the answer to Step 1110 is NO, Step804 is ended (1112).

Through the processing described above, the sum of the value of timeinformation indicating a time at which an operator in the queryexecution module 226 has executed processing last time and the value oftime information registered in the query execution tree graph analysisresult management table 235 is stored in the next ignition time holdingarea 234. In other words, the next ignition time holding area 234 storesa next ignition time for each operator, which is the time when theoperator is to start processing next.

FIG. 12 is a flow chart illustrating the HBT insertion (or generation)processing in Step 805 of FIG. 8.

First, the HBT generation module 224 of FIG. 2 obtains a current systemtimestamp held in the system timestamp holding area 232 (1202). Next,the HBT generation module 224 obtains the oldest next ignition systemtime that is held in the next ignition time holding area 234 (1203). TheHBT generation module 224 then compares the obtained current systemtimestamp against the obtained next ignition system time to determinewhether or not it is true that the value of the current system timestampis equal to or larger than the value of the next ignition system time(current system timestamp value≧next ignition system time) (1204).

When the answer to Step 1204 is YES, the HBT generation module 224obtains a final data input time held in the HBT generation-use dataprocessing time holding area 233. The HBT generation module 224 comparesthe obtained final data input time against the next ignition system timeobtained in Step 1203, to thereby determine whether or not it is truethat the final data input time is smaller than the next ignition systemtime (final data input time<next ignition system time) (1206).

When the answer to Step 1206 is YES, the HBT generation module 224updates the final data input time held in the HBT generation-use dataprocessing time holding area 233 with the value of the next ignitionsystem time obtained in Step 1203 (1207). The HBT generation module 224then transmits an HBT of this next ignition system time (1208).

When Step 1208 is finished, or when the answer to step 1206 is NO, theHBT generation module 224 deletes from the next ignition time holdingarea 234 the next ignition system time that has been obtained in Step1202 (1209).

When Step 1209 is finished, or when the answer to Step 1204 is NO, Step805 is ended (1210).

In Step 1203, the oldest next ignition system time that is held in thenext ignition time holding area 234 is obtained. Alternatively, a nextignition time that is the latest among ones equal to or smaller in valuethan the current time may be obtained in Step 1203 and time informationthat is equal to or smaller in value than this next ignition time may bedeleted in Step 1209.

Through the processing described above, the HBT generation module 224transmits an HBT of a next ignition system time when a condition thatthe value of the current system timestamp is equal to or larger than thevalue of the next ignition system time while the final data input timeis smaller than the next ignition system time is met. This enables theoperators in the execution tree 241 ₁ of FIG. 6 to start processingwithout waiting for the arrival of the stream data 21.

FIG. 13 is a sequence diagram exemplifying the next ignition timecalculation processing and the HBT generation processing.

FIG. 13 is described with reference to the stream data receiving module221, the HBT generation module 224 ₁, a next ignition time holding area234 ₁, an HBT generation-use data processing time holding area 233 ₁, anHBT generation module 224 ₂, a next ignition time holding area 234 ₂, anHBT generation-use data processing time holding area 233 ₂, the windowoperator 611, and the window operator 612, which are illustrated in FIG.6, and the next ignition time calculating module 223 and the systemtimestamp holding area 232, which are illustrated in FIG. 2. Thedescription also uses the flow charts of FIGS. 8, 10, 11, and 12. Thequery execution tree scheduler 222 illustrated in FIG. 2 controls theprocessing execution order of the HBT generation module 224 ₁, the HBTgeneration module 224 ₂, the window operator 611, and the windowoperator 612.

First, the stream data 21 ₁ of FIG. 6 is input to the stream datareceiving module 221 (1301). As illustrated in FIGS. 3 and 4, thetemperature stream data 21 ₁ has a format that includes the temperaturesensor ID 302, the device ID 303, and the temperature 304. In Step 1301,the temperature sensor ID 302 has a value “1001”, the device ID 303 hasa value “201”, and the temperature 304 has a value “23° C”. The formatof the temperature stream data 21 ₁ in Step 1301 is simplified in thedrawing, and “23° C”. alone is illustrated.

Next, the stream data receiving module 221 obtains a current time “9:00”held in the system timestamp holding area 232 (1302), stores “9:00” asthe value of the system timestamp 305, and transmits the stream data 21₁ to the HBT generation module 224 ₁ (1303).

Following the flow chart of FIG. 10, the HBT generation module 224 ₁registers the input time information “9:00” of the received stream data21 ₁ in the next ignition time holding area 234 of the HBT generationmodule 224 that is not the HBT generation module 224 ₁ which has beengiven YES as the answer to Step 1002 and which has received a tuple“9:00, 23° C”. of the stream data 21 ₁ in Step 1003, namely, the nextignition time holding area 234 ₂ of the HBT generation module 224 ₂(1304). The HBT generation module 224 ₁ next updates the final datainput time of the HBT generation-use data processing time holding area233 ₁ with the value “9:00” of the input time information of thereceived stream data 21 ₁ (1305), and transmits the tuple “9:00, 23° C”.to the window operator 611 (1306).

The window operator 611 executes processing unique to the windowoperator 611, and then executes processing of calculating a nextignition time. The flow chart of FIG. 11 is followed and YES is given asthe answer to Step 1102, and hence a value “9:02” is registered in thenext ignition time holding area 234 ₁ and in the next ignition timeholding area 234 ₂, as the sum of the value of the time information“9:00” attached to the tuple “9:00, 23° C”. which has been input to thewindow operator 611 and the value of the sliding window size “2 minutes”registered in the row 704 of the query execution tree graph analysisresult management table 235 of FIG. 7 (1308, 1309). In the next ignitiontime holding area 234 ₂, the registration of the value “9:02” is anaddition as opposed to overwrite, thus changing the time informationstored in the next ignition time holding area 234 ₂ to “9:00, 9:02”.Then, the answer is NO in all of Steps 1104, 1106, 1108, and 1110, andthe processing is ended. The window operator 611 also attaches to thetuple a plus flag indicating that the tuple has become a processingtarget, and transmits the resultant tuple “+, 9:03, 23° C”. to thefilter operator 613 of FIG. 6 (stores the tuple in the operator joiningqueue 236 that links the window operator 611 with the filter operator613) (1311).

Following the flow chart of FIG. 12, the HBT generation module 224 ₂obtains in Step 1202 the current system timestamp “9:00” held in thesystem timestamp holding area 232 (1321), and obtains in Step 1203 theoldest next ignition system time “9:00” held in the next ignition timeholding area 234 ₂ (1322). In Step 1204, the answer is YES because therelation “current system timestamp “9:00”≧next ignition system time“9:00”” is satisfied, and a final data input time “−(no data is storedbecause an update has not been made)” of the HBT generation-use dataprocessing time holding area 233 ₂ is obtained in Step 1205 (1323). InStep 1206, the answer is YES because the relation “final data input time“−(no data is stored because an update has not been made)”<next ignitionsystem time “9:00”” is satisfied, and the final data input time held inthe HBT generation-use data processing time holding area 233 ₂ isupdated in Step 1207 with the next ignition system time “9:00” obtainedin Step 1322 (1324). In Step 1208, an HBT “HBT, 9:00” of the nextignition system time “9:00” obtained in Step 1322 is transmitted to thewindow operator 612 (1325). In Step 1209, the next ignition system time“9:00” obtained in Step 1322 is deleted from the next ignition timeholding area 234 ₂ (1326). The window operator 612, which is agroup-based row window operator (Partitioned window), does not executeany processing upon reception of the HBT “HBT, 9:00”, and transmits theHBT “HBT, 9:00” to the filter operator 614 (stores the HBT in theoperator joining queue 236 that links the window operator 612 with thefilter operator 614) (1327).

Following the flow chart of FIG. 12, the HBT generation module 224 ₁obtains in Step 1202 a current system timestamp “9:01” held in thesystem timestamp holding area 232 (1331), and obtains in Step 1203 theoldest next ignition system time “9:02” held in the next ignition timeholding area 234 ₁ (1332). In Step 1204, the answer is NO because therelation “current system time “9:01”≧next system ignition time “9:02””is not satisfied, and the processing is ended.

Similarly, following the flow chart of FIG. 12, the HBT generationmodule 224 ₂ obtains in Step 1202 a current system timestamp “9:01” heldin the system timestamp holding area 232 (1341), and obtains in Step1203 the oldest next ignition system time “9:02” held in the nextignition time holding area 234 ₁ (1342). In Step 1204, the answer is NObecause the relation “current system time “9:01”≧next system ignitiontime “9:02”” is not satisfied, and the processing is ended.

Following the flow chart of FIG. 12, the HBT generation module 224 ₁obtains in Step 1202 the current system timestamp “9:02” held in thesystem timestamp holding area 232 (1351), and obtains in Step 1203 theoldest next ignition system time “9:02” held in the next ignition timeholding area 234 ₁ (1352). In Step 1204, the answer is YES because therelation “current system timestamp “9:02”≧next ignition system time“9:02”” is satisfied, and a final data input time “9:00” of the HBTgeneration-use data processing time holding area 233 ₁ is obtained inStep 1205 (1353). In Step 1206, the answer is YES because the relation“final data input time “9:00”” <next ignition system time “9:02”” issatisfied, and the final data input time held in the HBT generation-usedata processing time holding area 233 ₁ is updated in Step 1207 with thenext ignition system time “9:02” obtained in Step 1352 (1354). In Step1208, an HBT “HBT, 9:02” of the next ignition system time “9:02”obtained in Step 1352 is transmitted to the window operator 611 (1355).In Step 1209, the next ignition system time “9:02” obtained in Step 1352is deleted from the next ignition time holding area 234 ₁ (1356). Thewindow operator 611 transmits the HBT “HBT, 9:02” to the filter operator613 of FIG. 6 (stores the HBT in the operator joining queue 236 thatlinks the window operator 611 with the filter operator 613) (1357). TheHBT “HBT, 9:02” pushes the tuple “+, 9:00, 23° C”. transmitted in Step1311 out of its processing target status (the tuple of 9:00 ceases to bea processing target at 9:02 due to the “Range 2 minutes” definition). Aminus flag (−) indicating that a tuple is no longer a processing targetis attached to the tuple, and the resultant tuple “−, 9:00, 23° C”. istransmitted to the filter operator 613 of FIG. 6 (the tuple is stored inthe operator joining queue 236 that links the window operator 612 withthe filter operator 613) (1358).

Similarly, following the flow chart of FIG. 12, the HBT generationmodule 224 ₂ obtains in Step 1202 the current system timestamp “9:02”held in the system timestamp holding area 232 (1361), and obtains inStep 1203 the oldest next ignition system time “9:02” held in the nextignition time holding area 234 ₂ (1362). In Step 1204, the answer is YESbecause the relation “current system timestamp “9:02”≧next ignitionsystem time “9:02”” is satisfied, and a final data input time “9:00” ofthe HBT generation-use data processing time holding area 233 ₂ isobtained in Step 1205 (1363). In Step 1206, the answer is YES becausethe relation “final data input time “9:00”<next ignition system time“9:02”” is satisfied, and the final data input time held in the HBTgeneration-use data processing time holding area 233 ₂ is updated inStep 1207 with the next ignition system time “9:02” obtained in Step1362 (1364). In Step 1208, the HBT “HBT, 9:02” of the next ignitionsystem time “9:02” obtained in Step 1362 is transmitted to the windowoperator 612 (1365). In Step 1209, the next ignition system time “9:02”obtained in Step 1362 is deleted from the next ignition time holdingarea 234 ₂ (1366). The window operator 612 transmits the HBT “HBT, 9:02”to the filter operator 614 of FIG. 6 (stores the HBT in the operatorjoining queue 236 that links the window operator 612 with the filteroperator 614) (1367). The reception of the HBT “HBT, 9:02” at the windowoperator 612 does not cause a switch to another processing target.

Next, the stream data 21 ₂ of FIG. 6 is input to the stream datareceiving module 221 (1371). The humidity stream data 21 ₂ has a formatthat includes the humidity sensor ID 312, the device ID 313, and thehumidity 314 as illustrated in FIGS. 3B and 4. In Step 1371, thehumidity sensor ID 312 has a value “2001”, the device ID 313 has a value“201”, and the humidity 304 has a value “67%”. The format of thehumidity stream data 21 ₂ in Step 1371 is simplified in the drawing, and“67%” alone is illustrated.

Next, the stream data receiving module 221 obtains a current time “9:03”held in the system timestamp holding area 232 (1372), stores “9:03” asthe value of the system timestamp 315, and transmits the stream data 21₂ to the HBT generation module 224 ₂ (1373).

Subsequently, the same processing is repeated.

Summary of the First Embodiment

In a stream data processing method where part of stream data is definedas a processing target by a window and an HBT which indicates theadvance of time is inserted (generated and added) to the stream data,time information of the received stream data is stored in a nextignition time holding area as a next ignition time, which is a time whenthe HBT is inserted by an HBT generation module for generating the HBT.A processing module that generates the HBT at a time different from thetime of reception of the stream data is extracted out of a query thatindicates how the stream data is to be processed. Based on the extractedprocessing module and the time information indicating the time ofreception of the stream data, the next ignition time is calculated andstored in the next ignition time holding area. The HBT generation modulegenerates the HBT at the ignition time held in the next ignition timeholding area. The first embodiment has described that inserting timecontrol information at the time when it is necessary, which is an objectof this invention, is accomplished through the processing describedabove.

As described above, in the processing according to this invention whichis capable of inserting time control information at the time when it isnecessary, the amount of time control information is correspondinglyreduced. At the same time, the stream data processing is small inlatency because time control information is inserted at the timing whena processing module needs time control information.

The first embodiment of this invention has been described above.

This invention is not limited to the first embodiment described above,and various kinds of modifications may be made within the scope of thegist of this invention. As described hereinbelow, the same or furthereffects may be obtained by embodiments different from the firstembodiment, or further effects may be obtained by combining theembodiments with the first embodiment.

To give an example, in the flow chart of FIG. 9 and the sequence diagramof FIG. 13 exemplifying the next ignition time calculation processingand the HBT generation processing, a next ignition time is stored inevery next ignition time holding area. Not all of the next ignition timeholding areas need to store a next ignition time if whether or not aspecific next ignition time holding area is to store a next ignitiontime is determined as illustrated in a flow chart of FIG. 14.

The flow chart of FIG. 14 is described below.

The stream data processing module 220 repeats the following processingfor every HBT generation module 224 _(n) (1402).

When the answer to Step 1403 is YES in the previous round, whether ornot the target HBT generation module 224 _(n) has a parent-childrelation in the graph structure of the execution tree with the targetoperator whose next ignition time is about to be stored is determined(1403). Whether or not there is a parent-child relation is determined bywhether or not two target operators are along a path on which the streamdata 21 travels through the execution tree 241 ₁ of FIG. 6. In the caseof the join operator 615 or other operators that handle two or moreinputs of stream data, the output side operator has a parent-childrelation with an operator of any one of the input side operators. Forexample, the aggregation operator 616 and the HBT generation module 224₁ are in a parent-child relation in FIG. 6.

When Step 1404 is finished, or when the answer to Step 1403 is NO, thenext ignition time is registered in the next ignition time holding area234 _(n) of the target HBT generation module 224 _(n) (1404). When Steps1403 and 1404 have been executed for every HBT generation module 224_(n), the processing is ended (1405).

In the flow chart of FIG. 14, whether to store a next ignition time in anext ignition time holding area is determined when the next ignitiontime is about to be stored. Alternatively, the target operator maydetermine which next ignition time holding area is to store a nextignition time and store the decision in a table in advance, and hencethe table is referred to when necessary.

Second Embodiment

A second embodiment of this invention is described below.

The first embodiment has described that a wait in the query executionmodule 226 may be solved in the stream data processing sever 100 bymaking the HBT generation module 224 generate an HBT for advancing timeduring a period in which no data is generated at the time when the HBTis needed.

The second embodiment discusses a case in which a plurality of computersare involved and time information in a first computer is used to executestream data processing in a second computer. In this case, too, aproblem similar to the wait problem of the query execution module 226described above arises due to the need to transmit the time informationin the first computer to the second computer.

The second embodiment is characterized in that, in a setting in whichcontains a plurality of computers are involved and time information in afirst computer is used to execute stream data processing in a secondcomputer, the time information in the first computer is transmitted tothe second computer at the time when time control information is needed.The time control information in the second embodiment is discriminatedfrom an HBT used within the query execution module 226, and is called asystem timestamp tuple (STT). The STT has a format similar to that ofthe HBT, and includes an STT flag, which indicates that it is an STT,and time information, which indicates the time of generation of the STT.The STT may have other formats.

The second computer calculates a next ignition time in the mannerdescribed in the first embodiment, and transmits the calculated nextignition time to the first computer. Based on the next ignition time,the first computer transmits an STT to the second computer. The secondcomputer may use the processing method described in the first embodimentor any other arbitrary method to execute a query. For example, thesecond computer may execute a query without using an HBT.

FIG. 15 is a block diagram illustrating a configuration of the streamdata processing system to which the second embodiment of this inventionis applied and the system components related thereto.

The stream data processing sever 100 of FIG. 15 is the same as thestream data processing sever 100 of FIG. 1, and includes the CPU 11, thememory 12, the DISK 13, and the I/F 14. The memory 12 includes theoperating system (OS) 200, the command input module 210, and a streamdata processing module 220A. The operating system (OS) 200 and thecommand input module 210 of FIG. 15 are the same as the operating system(OS) 200 and the command input module 210 of FIG. 2. The stream dataprocessing module 220A of the stream data processing sever 100 isobtained by removing the system timestamp holding area and the nextignition time holding area from the stream data processing module 220 ofthe first embodiment, and adding an STT receiving module 1562.

An application operation server 1500 includes a CPU 1501, a memory 1502,a DISK 1503, and an I/F 1504. The memory 1502 includes an operatingsystem (OS) 1510, a command input module 1520, and a stream datagenerating application 1530. The stream data processing sever 100 andthe application operation server 1500 are connected to the network 112illustrated in FIG. 1 via the I/F 14 and the I/F 1504, respectively.

The second embodiment of this invention is outlined with reference toFIG. 15. The application operation server 1500 generates the stream data21, attaches time information held by the application operation server1500 to the generated stream data 21, and transmits the stream data 21to the stream data processing sever 100. The stream data processingsever 100 reads the stream data 21 according to a query given from theuser 114 through the computer 115, or a query that is input from anapplication run on the computer 115. The stream data processing sever100 converts the read stream data into significant information based onthe time information held by the application operation server 1500, andthen outputs the output result 23. Significant information is, forexample, information that is converted into a value averaged over agiven period of time, because measured values of the temperature sensornode 101 of FIG. 1 are in the form of a data sequence of measured valueswhich is incomprehensible to the users 114 and 116.

The configuration of the stream data processing sever 100 is describedin detail below.

The stream data processing module 220A includes a stream data receivingmodule 1561, the STT receiving module 1562, a stream data processingexecution module 1563, a next ignition time calculating module 1564, aquery execution tree graph analyzing module 1565, a query execution-usetime holding area 1571, an input stream data holding buffer 1572, aquery execution tree analysis result management table 1573, an operatorjoining queue 1574, and an output result holding buffer 1575.

The input stream data holding buffer 1572 is the same as the inputstream data holding buffer 231.

The stream data receiving module 1561 obtains data from the input streamdata holding buffer 1572, and outputs the data to the stream dataprocessing execution module 1563. In this embodiment where data isprocessed based on time information that is attached to the data by theapplication operation server 1500, the current time of the system heldby the stream data processing sever 100 is not used.

The stream data processing execution module 1563 processes the streamdata 21 based on time information that is attached to the stream data 21by the application operation server 1500. Any processing method may beemployed. For example, the stream data processing execution module 1563may be a processing module that is a combination of the query executionmodule 226, the query execution tree scheduler 222, and the HBTgeneration module 224, which are illustrated in FIG. 2. In thisembodiment, operators as those in the query execution module 226,including window operation, filter operation, projection operation, joinoperation, and aggregation operation are arranged in a tree structure(execution tree). The stream data processing execution module 1563receives data output from the stream data receiving module 1561, andstores a result of processing executed respectively by operators in anexecution tree in the output result holding buffer 1575. Midway resultsof processing executed respectively by the operators are stored in theoperator joining queue 1574.

The operator joining queue 1574 and the output result holding buffer1575 are the same as the operator joining queue 236 and the outputresult holding buffer 237, respectively. The query execution treeanalyzing module 1565 and the query execution tree analysis resultmanagement table 1573 are the same as the query execution tree analyzingmodule 225 and the query execution tree analysis result management table235, respectively.

The next ignition time calculating module 1564 refers to the queryexecution tree analysis result management table 1573 to calculate a nextignition time based on time information of input stream data andsettings information of the query which is stored in the query executiontree analysis result management table 1573, and transmits the calculatednext ignition time to the application operation server 1500 via the I/F14 as a next ignition time message. The next ignition time calculatingmodule 1564 is called up when the stream data processing executionmodule 1563 executes an operator extracted by the query execution treeanalyzing module 1565.

The STT receiving module 1562 receives via the I/F 14 an STT transmittedfrom an STT generation module 1542 of the application operation server1500 which is described later. The STT receiving module 1562 holds timeinformation attached to the received STT in the query execution-use timeholding area 1571. The query execution-use time holding area 1571 is aarea where time information transmitted from the application operationserver 1500 is held. Based on this time information, the stream dataprocessing execution module 1563 executes a query.

The configuration of the application operation server 1500 is describednext in detail.

The command input module 1520 receives a command given from the user 114through the computer 115, or a command that is input from an applicationrun on the computer 115.

The stream data generating application 1530 includes a stream datageneration module 1531, a next ignition time message receiving module1541, the STT generation module 1542, a system timestamp holding area1551, and a next ignition time holding area 1552.

The system timestamp holding area 1551 is a area where the current timeof the system is held. The current time of the system in this embodimentis absolute time information (e.g., current time managed by the OS 1510)that the application operation server 1500 has. Alternatively, thecurrent time of the system may be a value updated with time informationthat is input from another computer.

The stream data generation module 1531 generates the stream data 21,attaches the current time of the system which is held in the systemtimestamp holding area 1551 to the generated stream data 21, andtransmits the stream data 21 to the stream data processing sever 100 viathe I/F 1504.

The next ignition time message receiving module 1541 receives via theI/F 1504 a next ignition time message transmitted from the next ignitiontime calculating module 1564 of the application operation server 1500,and stores time information attached to the next ignition time messagein the next ignition time holding area 1552. The next ignition timeholding area 1552 is a area in which a next ignition time attached tothe next ignition time message that is received by the next ignitiontime message receiving module 1541 is held.

The STT generation module 1542 refers to the system timestamp holdingarea 1551 and the next ignition time holding area 1552. Using thecurrent time of the system which is held in the system timestamp holdingarea 1551 and the next ignition time which is held in the next ignitiontime holding area 1552, the STT generation module 1542 transmits the STTvia the I/F 1504 to the stream data processing sever 100 at the ignitiontime. Details of this process are described later.

The stream data 21, the output result 23, next ignition time messages,STTs, and temporarily stored data, which is kept by an operator forprocessing, may have any data format including the tuple format (recordformat), the XML format, and the CSV file format. The tuple format isused in the example given below. The stream data 21, the output result23, the next ignition time messages, the STTs, and the temporarilystored data, which is kept by an operator for processing, do not need tobe actual data, and may include partially or entirely a pointer thatpoints to the actual data.

The application operation server 1500 may be a server that executesstream data processing. For example, the stream data generation module1531 may be the stream data processing module 220A illustrated in FIG.15. Then stream data processing may be divided between the firstcomputer and the second computer such that time information on whichstream data processing is performed by the first computer is used instream data processing executed by the second computer.

FIG. 16 is a flow chart illustrating overall processing of the streamdata processing sever 100 and the application operation server 1500.

First, the query execution tree analyzing module 1565 of the stream dataprocessing sever 100 illustrated in FIG. 15 extracts an ignitionoperator from a query execution tree of a registered query, andregisters the ignition operator in the query execution tree analysisresult management table 1573 (1602). Details of Step 1602 are the sameas in the flow chart of FIG. 9.

Next, the next ignition time calculating module 1564 of the stream dataprocessing sever 100 calculates a next ignition time and transmits anext ignition time message to the application operation server 1500(1603). Details of Step 1603 are described later with reference to FIG.17.

Next, the next ignition time message receiving module 1541 of theapplication operation server 1500 receives the next ignition timemessage, and stores the next ignition time in the next ignition timeholding area 1552 of the application operation server 1500 (1604).

Next, the STT generation module 1542 of the application operation server1500 transmits an STT to the stream data processing sever 100 at theignition time held in the next ignition time holding area 1552 (1605).Details of Step 1605 are described later with reference to FIG. 18.

Next, whether or not the command input module 210 of the stream dataprocessing sever 100 has received a system end command is determined(1606). When the answer to Step 1606 is NO, the processing returns toStep 1602. When the answer to Step 1606 is YES, the processing of thestream data processing sever 100 is ended (1607).

FIG. 17 is a flow chart illustrating the next ignition time calculationprocessing in Step 1603 of FIG. 16.

First, the next ignition time calculating module 1564 of the stream dataprocessing sever 100 determines whether or not the target operator is asliding window operator (Range Window) that indicates a time period(1702). When the answer to Step 1702 is YES, the next ignition timecalculating module 1564 transmits the sum of the value of the timeinformation that is attached to a tuple input to the target operator inthe stream data processing execution module 1563 of FIG. 15 and thevalue of the sliding window size of the target operator that isregistered in the query execution tree graph analysis result managementtable 1573 to the application operation server 1500 as a next ignitiontime message (1703).

When Step 1703 is finished, or when the answer to Step 1702 is NO, thenext ignition time calculating module 1564 determines whether or not thetarget operator is jumping window operator (Jumping Window) thatindicates a time period (1704). When the answer to Step 1704 is YES, thenext ignition time calculating module 1564 transmits the sum of thevalue of the time information indicating a time at which the targetoperator in the stream data processing execution module 1563 hasexecuted processing last time and the value of the jumping window sizethat is registered in the query execution tree graph analysis resultmanagement table 1573 to the application operation server 1500 as a nextignition time message (1705).

When Step 1705 is finished, or when the answer to Step 1704 is NO, thenext ignition time calculating module 1564 determines whether or not thetarget operator is a relation-to-stream operator (IStream, DStream,IDStream) that indicates a time period and that causes delay (1706).When the answer to Step 1706 is YES, the next ignition time calculatingmodule 1564 transmits the sum of the value of the time information thatis attached to a tuple input to the target operator in the stream dataprocessing execution module 1563 and the value of the delay size that isregistered in the query execution tree graph analysis result managementtable 1573 to the application operation server 1500 as a next ignitiontime message (1707).

When Step 1707 is finished, or when the answer to Step 1706 is NO, thenext ignition time calculating module 1564 determines whether or not thetarget operator is a relation-to-stream operator (RStream) thatindicates a time period and that outputs at regular intervals (1708).When the answer to Step 1708 is YES, the next ignition time calculatingmodule 1564 transmits the sum of the value of the time informationindicating a time at which the target operator in the stream dataprocessing execution module 1563 has executed processing last time andthe value of the output interval of the target operator that isregistered in the query execution tree graph analysis result managementtable 1573 to the application operation server 1500 as a next ignitiontime message (1709).

When Step 1709 is finished, or when the answer to Step 1708 is NO, thenext ignition time calculating module 1564 determines whether or not thetarget operator is an operator (Sum, Count, Average, Min, Max, Median,Variable, Standard Deviation, Limit) that has a function of excludingghosts (1710). When the answer to Step 1710 is YES, the next ignitiontime calculating module 1564 transmits the sum of the value of the timeinformation that is attached to a tuple input to the target operator inthe stream data processing execution module 1563 and the value of theminimum time unit of the target operator that is registered in the queryexecution tree graph analysis result management table 1573 to theapplication operation server 1500 as a next ignition time message(1711).

When Step 1711 is finished, or when the answer to Step 1710 is NO, Step1603 is ended (1712).

Through the processing described above, a next ignition time of anignition operator is calculated based on the sum of time informationthat is attached to a tuple input to the target operator and timeinformation that is registered in the query execution tree graphanalysis result management table 1573, and the calculated next ignitiontime is transmitted as a next ignition time message to the applicationoperation server 1500.

FIG. 18 is a flow chart illustrating the processing that is executed bythe STT generation module 1542 of the application operation server 1500in Step 1605 of FIG. 16.

First, the STT generation module 1542 of FIG. 15 obtains a currentsystem timestamp held in the system timestamp holding area 1551 (1802).Next, the STT generation module 1542 obtains the oldest next ignitionsystem time that is held in the next ignition time holding area 1551(1803). The STT generation module 1542 then compares the obtainedcurrent system timestamp against the obtained next ignition system timeto determine whether it is true that the value of the current systemtime stamp is equal to or larger than the value of the next ignitionsystem time (current system timestamp value≧next ignition system time)(1804).

When the answer to Step 1804 is YES, the STT generation module 1542transmits an STT of the next ignition system time (1805). The STTgeneration module 1542 then deletes the next ignition system timeobtained in Step 1802 from the next ignition time holding area 1551(1806).

When Step 1806 is finished, or when the answer to Step 1804 is NO, Step1605 is ended (1807).

In Step 1803, the oldest next ignition system time that is held in thenext ignition time holding area 1551 is obtained. Alternatively, a nextignition time that is the latest among ones equal to or smaller than thevalue of the current time may be obtained in Step 1803 and timeinformation that is equal to or smaller than the value of this nextignition time may be deleted in Step 1806.

The second embodiment of this invention has been described above.

CONCLUSION

This invention is not limited to the first and second embodimentsdescribed above, and various kinds of modifications may be made withinthe scope of the gist of this invention. In addition, any combination ofthe first and second embodiments described above may be made.

For example, in the above embodiments, no limitation is placed on a sizeof the data to be held in the next ignition time holding areaillustrated in FIGS. 2 and 15. However, by defining a memory upper limitvalue, an appropriate processing may be performed when the upper limitvalue is exceeded. For example, deleting data that has old timeinformation, or suspending input stream data, or deleting and processing(shredding) part of input stream data may be employed.

In the embodiments described above, the next ignition time calculatingmodule and the query execution tree analyzing module are containedwithin the stream data processing sever 100. Alternatively, othercomputers than the stream data processing sever 100 may execute theprocessing of the next ignition time calculating module and the queryexecution tree analyzing module.

While the embodiments described above are examples in which the streamdata processing system processes time control information (HBT and STT),other systems than the stream data processing system such as a databasesystem may process the time control information of the embodimentsdescribed above.

In addition, in the above embodiments, the stream data processing sever100 and the application operation server 1500 is described as anarbitrary computer system, but a part or all of the processingsperformed in the stream data processing sever 100 and the applicationoperation server 1500 may be performed in the storage system.

In addition, the above embodiments have been made by taking an examplewhere the sensor base station 108 inputs the temperature data orhumidity data to the stream data processing sever 100 as the stream data21, but this invention is not limited thereto. For example, instead ofthe sensor base station 108, a sensor net server for managing a largenumber of sensor nodes may output measurement values from the sensornodes as the stream data 21, and the stream data processing sever 100may convert the measurement values into the output result 23 includingthe significant information that may be understood by the user 116 andprovide the output result 23 to the computer 117. In addition, the datainput to the stream data processing sever 100 may include taginformation read by an RFID reader and a data input from the computer113 serving as an RFID middleware system for centrally managing RFIDs.In addition, the data may include data input from the stock informationproviding server 118. In addition, the data input to the stream dataprocessing sever 100 may include traffic information such as obtainedfrom an ETC system, IC card information such as obtained from automaticticket gates and credit cards, financial information such as informationon stock prices, manufacturing process management information, callinformation, a system log, network access information, traceabilityindividual body information, monitor video metadata, and a Web clickstream.

As has been described, according to this invention, stream dataprocessing small in latency is accomplished while reducing the amount oftime control information by inserting (or generating) time controlinformation at the time when the time control information is needed. Inparticular, this invention may be applied to a financial application, atraffic information system, a traceability system, a sensor monitoringsystem, computer system management, and the like, which handle anenormous amount of stream data necessary to be processed in real time.

While the present invention has been described in detail and pictoriallyin the accompanying drawings, the present invention is not limited tosuch detail but covers various obvious modifications and equivalentarrangements, which fall within the purview of the appended claims.

1. A machine-readable medium for storing a stream data processingprogram for receiving, as primary information, stream data input to acomputer comprising a processor and a storage system, creating secondaryinformation by obtaining a given period of the received primaryinformation as a processing target, and generating time controlinformation indicating advance of time in addition to the primaryinformation, wherein the stream data processing program controls thecomputer to execute the procedures of: receiving the input stream dataas the primary information; calculating, by a time control informationgeneration module for generating, as the time control information, timeinformation at a time of reception of the primary information, a time atwhich the time control information is generated as a next ignition time,and storing the next ignition time in a next ignition time holding area,which is set in the storage system; generating the time controlinformation when current time information reaches the next ignition timeheld in the next ignition time holding area; and creating, uponreception of the generated time control information, secondaryinformation by obtaining the given period of the received primaryinformation as the processing target.
 2. The machine-readable medium forstoring a stream data processing program according to claim 1, whereinthe stream data processing program further controls the computer toexecute the procedures of: receiving and registering a query whichdefines processing specifics for creating the secondary information byobtaining the primary information; and creating a processing module forexecuting the processing specifics defined in the received query, andwherein the procedure of calculating, by the time control informationgeneration module for generating, as the time control information, thetime information at the time of the reception of the primaryinformation, the time at which the time control information is generatedas the next ignition time, and storing the next ignition time in thenext ignition time holding area, which is set in the storage system,comprises the procedures of: extracting a processing module that needsto generate the time control information at a time different from thetime of the reception of the primary information; and calculating thenext ignition time based on the extracted processing module and based onthe time information at the time of the reception of the primaryinformation.
 3. The machine-readable medium for storing a stream dataprocessing program according to claim 2, wherein the procedure ofcalculating, by the time control information generation module forgenerating, as the time control information, the time information at thetime of the reception of the primary information, the time at which thetime control information is generated as the next ignition time, andstoring the next ignition time in the next ignition time holding area,which is set in the storage system, comprises a procedure of creating aplurality of the time control information generation modules which areconnected to the processing module and generate the time controlinformation, and wherein the procedure of calculating the time at whichthe time control information is generated as the next ignition time, andstoring the next ignition time in the next ignition time holding area,which is set in the storage system, comprises the procedures of:determining whether or not one of the plurality of the time controlinformation generation modules has received the primary information;storing the time information of the received primary information in thenext ignition time holding area of another one of the plurality of thetime control information generation modules which is different from theone of the plurality of the time control information generation modulesthat has received the primary information; and storing the timeinformation of the received primary information in a time controlinformation generation-use data processing time holding area for storingthe time information processed by the plurality of the time controlinformation generation modules.
 4. The machine-readable medium forstoring a stream data processing program according to claim 3, whereinthe procedure of generating the time control information when thecurrent time information reaches the next ignition time held in the nextignition time holding area comprises the procedures of: obtaining acurrent time from a system timestamp holding area, which holds a currenttime of the computer; obtaining the next ignition time held in the nextignition time holding area; determining whether or not the obtainedcurrent time is equal to or larger than the next ignition time;obtaining, when the obtained current time is equal to or larger than thenext ignition time, a final data input time from the time controlinformation generation-use data processing time holding area, where afinal time at which the primary information has been input to the timecontrol information generation module is held; determining whether ornot the obtained final data input time is smaller than the next ignitiontime; updating, when the obtained final data input time is smaller thanthe next ignition time, the final data input time held in the timecontrol information generation-use data processing time holding area;generating time control information at the next ignition time; anddeleting, when the obtained final data input time is equal to or largerthan the next ignition time, the next ignition time from the nextignition time holding area.
 5. The machine-readable medium for storing astream data processing program according to claim 2, wherein theprocedure of extracting the processing module that needs to generate thetime control information at the time different from the time of thereception of the primary information comprises: a first procedure ofdetermining whether or not the processing module is a processing modulethat performs, on the primary information, sliding window operation inwhich a processing target range indicated by a time window that isspecified in the query is cut out, and registering, when the processingmodule is determined as the processing module that performs the slidingwindow operation, the processing module and a time size in a queryexecution tree graph analysis result management table, which is used tomanage the processing modules that need to generate the time controlinformation at the time different from the time of the reception of theprimary information; a second procedure of determining whether or notthe processing module is a processing module that performs, on theprimary information, jumping window operation in which a processingtarget range indicated by a time interval that is specified in the queryis cut out, and registering, when the processing module is determined asthe processing module that performs the jumping window operation, theprocessing module and the time interval in the query execution treegraph analysis result management table; a third procedure of determiningwhether or not the processing module is a processing module that outputsa query processing result with a delay, and registering, when theprocessing module is determined as the processing module that outputsthe query processing result with the delay, the processing module and adelay size in the query execution tree graph analysis result managementtable; a fourth procedure of determining whether or not the processingmodule is a processing module that outputs a group of the queryprocessing results at regular intervals, and registering, when theprocessing module is determined as the processing module that outputsthe group of the query processing results, the processing module and anoutput interval in the query execution tree graph analysis resultmanagement table; and a fifth procedure of determining whether or notthe processing module is a processing module with a function ofexcluding, from the query processing results, a processing result thathas zero as a length of time in which the processing result remains theprocessing target, and registering, when the processing module isdetermined as the processing module with the function of excluding theprocessing result that has zero, the processing module and a minimumtime unit in the query execution tree graph analysis result managementtable, and wherein at least one of the first procedure to the fifthprocedure is repeated for every processing module in a query executiontree that is created from the registered query.
 6. The machine-readablemedium for storing a stream data processing program according to claim5, wherein the procedure of calculating, by the time control informationgeneration module for generating, as the time control information, thetime information at the time of the reception of the primaryinformation, the time at which the time control information is generatedas the next ignition time, and storing the next ignition time in thenext ignition time holding area, which is set in the storage system,comprises the procedures of: determining whether or not the processingmodule is the processing module that performs, on the primaryinformation, the sliding window operation in which the processing targetrange indicated by the time window that is specified in the query is cutout, and registering, when the processing module is determined as theprocessing module that performs the sliding window operation, in thenext ignition time holding area, a value that is obtained by addinginput time information and the time size together, the time size beingregistered in the query execution tree graph analysis result managementtable; determining whether or not the processing module is theprocessing module that performs, on the primary information, the jumpingwindow operation in which the processing target range indicated by thetime interval that is specified in the query is cut out, andregistering, when the processing module is determined as the processingmodule that performs the jumping window operation, a value that isobtained by adding time information and the time interval together, thetime information indicating a time when the processing module hasexecuted processing, the time interval being registered in the queryexecution tree graph analysis result management table; determiningwhether or not the processing module is the processing module thatoutputs the query processing result with the delay, and registering,when the processing module is determined as the processing module thatoutputs the query processing result with the delay, in the next ignitiontime holding area, a value that is obtained by adding the input timeinformation and the delay size together, the delay size being registeredin the query execution tree graph analysis result management table;determining whether or not the processing module is the processingmodule that outputs the group of the query processing results at theregular intervals, and registering, when the processing module isdetermined as the processing module that outputs the group of the queryprocessing results, a value that is obtained by adding the timeinformation and the output interval together, the time informationindicating the time when the processing module has executed theprocessing, the output interval being registered in the query executiontree graph analysis result management table; and determining whether ornot the processing module is the processing module with the function ofexcluding, from the query processing results, the processing result thathas zero as the length of time in which the processing result remainsthe processing target, and registering, when the processing module isdetermined as the processing module with the function of excluding theprocessing result that has zero, in the next ignition time holding area,a value that is obtained by adding the input time information and theminimum time unit together, the minimum time unit being registered inthe query execution tree graph analysis result management table.
 7. Themachine-readable medium for storing a stream data processing programaccording to claim 5, wherein the procedure of calculating, by the timecontrol information generation module for generating, as the timecontrol information, the time information at the time of the receptionof the primary information, the time at which the time controlinformation is generated as the next ignition time, and storing the nextignition time in the next ignition time holding area, which is set inthe storage system, comprises the procedures of: determining for everytime control information generation module whether or not the timecontrol information generation module has a parent-child relation in agraph structure that is a tree structure with the extracted processingmodule; and storing, when it is determined that the time controlinformation generation module has the parent-child relation, the nextignition time in the next ignition time holding area.
 8. Themachine-readable medium for storing a stream data processing programaccording to claim 2, the computer further comprises: a first computer;and a second computer, the first computer generating the stream data,which is received as the primary information, attaching the timeinformation that is generated in the first computer to the primaryinformation, and transmitting the primary information to the secondcomputer, the second computer executing processing of creating thesecondary information by obtaining the given period of the receivedprimary information as the processing target, the first computertransmitting the time control information indicating the advance of thetime to the second computer in addition to the primary information,wherein the stream data processing program further controls the secondcomputer to execute the procedures of: extracting from the query theprocessing module that needs to generate the time control information atthe time different from the time of the reception of the primaryinformation, the query defining the processing specifics for creatingthe secondary information by obtaining the primary information; andcalculating the next ignition time based on the extracted processingmodule and based on the time information at the time of the reception ofthe primary information, and transmitting the next ignition time as anext ignition time message to the first computer, the next ignition timebeing the time at which the time control information generation modulefor generating the time control information generates the time controlinformation, and wherein the stream data processing program furthercontrols the first computer to execute the procedures of: receiving thenext ignition time and storing the received next ignition time in thenext ignition time holding area, where the next ignition time is held;and transmitting the time control information from the time controlinformation generation module to the second computer at the nextignition time held in the next ignition time holding area.
 9. Themachine-readable medium for storing a stream data processing programaccording to claim 8, wherein the procedure of transmitting, by thefirst computer, the time control information from the time controlinformation generation module to the second computer at the nextignition time held in the next ignition time holding area comprises theprocedures of: obtaining a current time from a system timestamp holdingarea, which holds a current time of the first computer; obtaining thenext ignition time held in the next ignition time holding area;determining whether or not the obtained current time is equal to orlarger than the next ignition time; generating, when the obtainedcurrent time is equal to or larger than the next ignition time, the timecontrol information at the next ignition time; and deleting, when anobtained final data input time is equal to or larger than the nextignition time, the next ignition time from the next ignition timeholding area.
 10. The machine-readable medium for storing a stream dataprocessing program according to claim 8, wherein the procedure ofextracting, by the second computer, from the query the processing modulethat needs to generate the time control information at the timedifferent from the time of the reception of the primary information, thequery defining the processing specifics for creating the secondaryinformation by obtaining the primary information comprises: a sixthprocedure of determining whether or not the processing module is aprocessing module that performs, on the primary information, slidingwindow operation in which a processing target range indicated by a timewindow that is specified in the query is cut out, and registering, whenthe processing module is determined as the processing module thatperforms the sliding window operation, the processing module and a timesize in a query execution tree graph analysis result management table,which is used to manage the processing modules that need to generate thetime control information at the time different from the time of thereception of the primary information; a seventh procedure of determiningwhether or not the processing module is a processing module thatperforms, on the primary information, jumping window operation in whicha processing target range indicated by a time interval that is specifiedin the query is cut out, and registering, when the processing module isdetermined as the processing module that performs the jumping windowoperation, the processing module and the time interval in the queryexecution tree graph analysis result management table; an eighthprocedure of determining whether or not the processing module is aprocessing module that outputs a query processing result with a delay,and registering, when the processing module is determined as theprocessing module that outputs the query processing result with thedelay, the processing module and a delay size in the query executiontree graph analysis result management table; a ninth procedure ofdetermining whether or not the processing module is a processing modulethat outputs a group of the query processing results at regularintervals, and registering, when the processing module is determined asthe processing module that outputs the group of the query processingresults, the processing module and an output interval in the queryexecution tree graph analysis result management table; and a tenthprocedure of determining whether or not the processing module is aprocessing module with a function of excluding, from the queryprocessing results, a processing result that has zero as a length oftime in which the processing result remains the processing target, andregistering, when the processing module is determined as the processingmodule with the function of excluding the processing result that haszero, the processing module and a minimum time unit in the queryexecution tree graph analysis result management table, and wherein atleast one of the sixth procedure to the tenth procedure is repeated forevery processing module in a query execution tree that is created fromthe registered query.
 11. The machine-readable medium for storing astream data processing program according to claim 10, wherein theprocedure of receiving, by the first computer, the next ignition timeand storing the received next ignition time in the next ignition timeholding area, where the next ignition time is held comprises theprocedures of: determining whether or not the processing module is theprocessing module that performs, on the primary information, the slidingwindow operation in which the processing target range indicated by thetime window that is specified in the query is cut out, and registering,when the processing module is determined as the processing module thatperforms the sliding window operation, in the next ignition time holdingarea, a value that is obtained by adding input time information and thetime size together, the time size being registered in the queryexecution tree graph analysis result management table; determiningwhether or not the processing module is the processing module thatperforms, on the primary information, the jumping window operation inwhich the processing target range indicated by the time interval that isspecified in the query is cut out, and registering, when the processingmodule is determined as the processing module that performs the jumpingwindow operation, a value that is obtained by adding time informationand the time interval together, the time information indicating a timewhen the processing module has executed processing, the time intervalbeing registered in the query execution tree graph analysis resultmanagement table; determining whether or not the processing module isthe processing module that outputs the query processing result with thedelay, and registering, when the processing module is determined as theprocessing module that outputs the query processing result with thedelay, in the next ignition time holding area, a value that is obtainedby adding the input time information and the delay size together, thedelay size being registered in the query execution tree graph analysisresult management table; determining whether or not the processingmodule is the processing module that outputs the group of the queryprocessing results at the regular intervals, and registering, when theprocessing module is determined as the processing module that outputsthe group of the query processing results, a value that is obtained byadding the time information and the output interval together, the timeinformation indicating the time when the processing module has executedthe processing, the output interval being registered in the queryexecution tree graph analysis result management table; and determiningwhether or not the processing module is the processing module with thefunction of excluding, from the query processing results, the processingresult that has zero as the length of time in which the processingresult remains the processing target, and registering, when theprocessing module is determined as the processing module with thefunction of excluding the processing result that has zero, in the nextignition time holding area, a value that is obtained by adding the inputtime information and the minimum time unit together, the minimum timeunit being registered in the query execution tree graph analysis resultmanagement table.
 12. A computer system, comprising: a processor; astorage system; and an interface, the computer system obtaining, asprimary information, stream data which is set in the storage system andinput via the interface, creating secondary information by obtaining agiven period of the obtained primary information, and generating timecontrol information indicating advance of time in addition to theprimary information, the computer system further comprising: a queryexecution tree analyzing module for extracting from a query a processingmodule that needs to generate the time control information at a timedifferent from a time of reception of the primary information, the queryindicating processing specifics for creating the secondary informationby obtaining the primary information; a next ignition time calculatingmodule for calculating an ignition time from based on extractedprocessing module and based on time information at the time of thereception of the primary information, and storing the ignition time in anext ignition time holding area, which is set in the storage system, theignition time being a time at which a time control informationgeneration module for generating the time control information generatesthe time control information; and a time control information generationmodule for generating, as the time control information, the timeinformation at the time of the reception of the primary information,wherein the time control information generation module generates thetime control information when current time information reaches theignition time held in the next ignition time holding area.
 13. Acomputer system, comprising: a first computer; and a second computer,the first computer generating stream data, which is received as primaryinformation, attaching time information that is generated in the firstcomputer to the primary information, and transmitting the primaryinformation to the second computer, the second computer creatingsecondary information by obtaining a given period of the receivedprimary information, the first computer transmitting time controlinformation indicating advance of time to the second computer inaddition to the primary information, the computer system furthercomprising: a query execution tree analyzing module of the secondcomputer, for extracting from a query a processing module that needs togenerate the time control information at a time different from a time ofreception of the primary information, the query indicating processingspecifics for creating the secondary information by obtaining theprimary information; a next ignition time calculating module of thesecond computer, for calculating an ignition time based on the extractedprocessing module and based on time information at the time of thereception of the primary information, and transmitting the ignition timeto the first computer, the ignition time being a time at which a timecontrol information generation module for generating the time controlinformation generates the time control information; a next ignition timemessage receiving module of the first computer, for receiving theignition time and storing the received ignition time in a next ignitiontime holding area, where the ignition time is held; and a time controlinformation generation module of the first computer, for transmittingthe time control information to the second computer at the ignition timeheld in the next ignition time holding area.